home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / doc / www_talk.arc / 000316_davis@dri.cornell.edu _Thu Nov 12 21:28:42 1992.msg < prev    next >
Internet Message Format  |  1992-11-30  |  3KB
  1. Return-Path: <davis@dri.cornell.edu>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA08307; Thu, 12 Nov 92 21:28:42 MET
  4. Received: by dxmint.cern.ch (dxcern) (5.57/3.14)
  5.     id AA06769; Thu, 12 Nov 92 21:41:34 +0100
  6. Received: by willow.tc.cornell.edu id AA13231
  7.   (5.65c/IDA-1.4.4 for www-talk@nxoc01.cern.ch); Thu, 12 Nov 1992 15:40:14 -0500
  8. Date: Thu, 12 Nov 1992 15:40:14 -0500
  9. From: Jim Davis <davis@dri.cornell.edu>
  10. Message-Id: <199211122040.AA13231@willow.tc.cornell.edu>
  11. To: www-talk@nxoc01.cern.ch
  12. Subject: Re: indexes as links rather than documents
  13.  
  14.  
  15. As I understand it, the distinction between an indexed document
  16. and an ordinary one is that an indexed document is really
  17. an abstract document.   Once you provide the index terms,
  18. then it is concrete document.  So a Dictionary is abstract
  19. until I send it a keyword, then I get back a real document,
  20. the definition for the word.
  21.  
  22. In the case of the dictionary, of course, one could argue
  23. that the Dictionary as a whole is also a concrete document,
  24. since it would be possible to just read it cover to cover.
  25. On the other hand, this makes less sense if the abstract
  26. document is performing some kind of computation on the
  27. search words, for example, running finger, or even adding
  28. something to a database.  Then there is no meaningful document
  29. without the index.
  30.  
  31. If that's the right way to think, then it makes sense to put
  32. the semantics into the link, because it's more extensible.
  33. In the case of the index, the user is prompted for keywords,
  34. because that's the input to the computation.  But 
  35. there are many kinds of abstract documents, and many possible
  36. computations to yield concrete documents, and for many of
  37. these there will be other kinds of input requirements.
  38. It seems inelegant to support these by having the abstact
  39. document indicate its input requirements by returning a
  40. document with a special purpose tag (eg <ISINDEX>), since
  41. this will mean that every new kind of input will require a new
  42. tag in HTML.
  43.  
  44. Maybe this can be addressed in HTML2, by some process of negotiation
  45. between server (abstract document) and user/client.  e.g the document
  46. sends something back saying "I will give you a page of text but
  47. first send me at least one line of ascii".  If this is the
  48. right approach, then we need a means of describing data types and prompts.
  49. The negotiation might take several exchanges, or it might be done
  50. by having the server return a small program, something like a decision
  51. tree, to prompt the user for all meaningful values required for
  52. the input.
  53.  
  54. While I am on the topic, though, the protocol should be designed
  55. such that software agents on the client side can obtain documents
  56. without having to negotiate, if they have all the desired inputs
  57. ready to hand.  I don't want my user agent to have to parse X
  58. windows protocols in order to answer on by behalf.
  59.  
  60. Best wishes